Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SYCL][NFC] Refactor #includes #16030

Open
wants to merge 11 commits into
base: sycl
Choose a base branch
from
Open

[SYCL][NFC] Refactor #includes #16030

wants to merge 11 commits into from

Conversation

AlexeySachkov
Copy link
Contributor

@AlexeySachkov AlexeySachkov commented Nov 8, 2024 •
edited
Loading

This patch is a collection of various cleanups made in public headers:

  • Cleaned up many unnecessary includes. It doesn't change total amount of header files we use in total by sycl.hpp, but makes our code cleaner
  • Made it so there are no headers (except for backend/%backend_name%.hpp) depend on backend.hpp and it is (almost) only included by sycl.hpp, so that we can make it an opt-in header
  • Removed types.hpp in favor of direct use of vector.hpp
  • Added missing includes and forward-declarations to places where we relied on implicit includes
  • Moved certain helper function declarations/definitions to better places (common utils to utils headers, library-only declarations to library headers, etc.)

@AlexeySachkov
[SYCL][NFC] Refactor #includes
6303959 
This patch is a collection of various cleanups made in public headers:
- Cleaned up many unnecessary includes. It doesn't change total amount
  of header files we use in total by `sycl.hpp`, but makes our code
  cleaner
- Made it so there are no headers depending on `backend.hpp` and it is
  only included by `sycl.hpp`, so that we can make it an opt-in header
- Removed `types.hpp` in favor of direct use of `vector.hpp`
- Added missing includes and forward-declarations to places where we
  relied on implicit includes
- Moved certain helper function declarations/definitions to better
  places (common utils to utils headers, library-only declarations to
  library headers, etc.)
AlexeySachkov
AlexeySachkov commented Nov 8, 2024
View reviewed changes
Copy link
Contributor Author

@AlexeySachkov AlexeySachkov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will make the patch ready for review, even though CI fails: by some reason checkout step started to consistently fail for my PR - I will try to figure that our while I'm waiting for feedback and applying it.

sycl/include/sycl/vector.hpp Outdated Show resolved Hide resolved
sycl/test/CMakeLists.txt
@@ -15,7 +15,6 @@ set(SYCL_THREADS_LIB ${CMAKE_THREAD_LIBS_INIT})

# TEST_INCLUDE_PATH is used for syntax-only verification of type information.
list(APPEND test_includes ${SYCL_INCLUDE})
list(APPEND test_includes ${SYCL_INCLUDE}/sycl)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note for reviewers: without this change test/gdb/printer.cpp failed to compile. The reason for that is because in program_impl.hpp we have #include <detail/ur.hpp> line.

We have two detail/ur.hpp headers: one under sycl/include/sycl and another under sycl/source. During the RT build we only have sycl/include and sycl/source include paths, so we take the right header and everything works fine.
However, for this specific test we add an extra include path, which makes a wrong file to be included and leads to missing declaration of convertUrBackend (which is moved into the library by this PR). I do not see any failures which would be caused by this particular change and I also don't quite understand why do we need this path at all.

@AlexeySachkov AlexeySachkov marked this pull request as ready for review November 8, 2024 17:50
@AlexeySachkov AlexeySachkov requested review from a team as code owners November 8, 2024 17:50
@AlexeySachkov AlexeySachkov mentioned this pull request Nov 8, 2024
Draft
@AlexeySachkov AlexeySachkov requested a review from a team as a code owner November 9, 2024 10:49
sarnex
sarnex approved these changes Nov 12, 2024
View reviewed changes
Copy link
Contributor

@sarnex sarnex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@AlexeySachkov
Copy link
Contributor Author

@intel/llvm-reviewers-cuda, @intel/dpcpp-nativecpu-pi-reviewers, could you please take a look?

ldrumm
ldrumm approved these changes Nov 14, 2024
View reviewed changes
Copy link
Contributor

@ldrumm ldrumm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like nice cleanup. Small nits to think about, but generally LGTM

sycl/include/sycl/vector.hpp
@@ -51,7 +51,8 @@

namespace sycl {

// TODO: Fix in the next ABI breaking windows.
// TODO: It should be within _V1 namespace, fix in the next ABI breaking
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a ticket for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I've submitted #16086

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how useful it would be. What I did for the last major breaking release is simply grep for abi and fix the code.

sycl/source/detail/adapter.hpp
@@ -35,6 +34,7 @@

namespace sycl {
inline namespace _V1 {
enum class backend : char;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forward declarations of enums classes make me slightly uneasy since the storage types can end up mismatching (which can't happen with a struct forward declaration for example). I've had to track down nasty bugs due to this in the past.

Do we have a way to ensure that if the complete declaration changes type, we know to update all of these forward decls?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a way to ensure that if the complete declaration changes type, we know to update all of these forward decls?

I actually had to type the exact type here, or otherwise compiler complained that forward declaration doesn't match the actual definition. From that point of view, I think it should be safe for us to say that such mechanism exists.

Note that I was using clang as compiler and it could have been a diagnostic specific to it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@aelovikov-intel aelovikov-intel aelovikov-intel approved these changes

@aarongreig aarongreig aarongreig approved these changes

@sarnex sarnex sarnex approved these changes

@ldrumm ldrumm ldrumm approved these changes

@hdelan hdelan Awaiting requested review from hdelan hdelan is a code owner automatically assigned from intel/llvm-reviewers-cuda

@uditagarwal97 uditagarwal97 Awaiting requested review from uditagarwal97 uditagarwal97 is a code owner automatically assigned from intel/llvm-reviewers-runtime

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@AlexeySachkov @ldrumm @sarnex @aarongreig @aelovikov-intel